What you Need to Know When Administering a SAS Viya Linux Environment

SAS Viya is a cloud-enabled, in-memory analytics engine that uses elastic, scalable, and fault-tolerant processing to address complex analytical challenges. It can be deployed in cloud, on-premises, or hybrid environments. In order to keep powerful systems like SAS Viya running smooth and efficiently, they must be maintained by professionals. What are 7 key things that all support professionals must know?

1. Getting to know where your software is deployed

There are several directories in your Viya installation that you will use frequently and that are especially relevant in maintaining a Viya environment. A few of note right away.

• Install directory
• CAS cache directory
• Deployment directory
• SAS workspace directory

The install directory is where all the files that pertain to the initial installation are located. It contains files such as inventory.ini, vars.yml, your license info, etc. Typically, this is /sasdepot

The deployment directory is where all of the SAS Viya software is actually deployed to. The default is to install to /opt/sas/* and the subdirectories contain all the binaries, logs, and other installation files.

The CAS cache directory is where Viya stores temporary files that cannot fit into memory. It typically defaults to /tmp but this location is not typically used due to its size restrictions, and it is normally changed using the CAS_DISK_CACHE value in vars.yml. The CAS cache directory is normally set up on a shared file system, so multiple CAS worker nodes can utilize this space effectively.

The SAS Workspace directory is where Viya processes older SAS programs using the SAS Programming Runtime Environment, otherwise known as SPRE or SAS kernel. This is the Viya replacement for the Compute Tier when compared to a SAS 9.4 installation. By default SASWORK points to /tmp but it is highly recommended to change this location, just as you would the CAS cache directory. The location can be changed by editing the “COMPUTESERVER_TMP_PATH=” option in the vars.yml file, located in your install directory but can also be modified post-installation in the SAS Foundation configuration files found in the deployment directory.

2.Know where your caslib’s are

Caslib’s are what users normally work with in a Viya environment. They are a container of data and metadata that get loaded into memory. It is vital that the physical location on the server is known and administrable, as data-access issues are a common complaint by users.

3. How to manually start services.

By default, Viya start/stop scripts are set up in the /etc/init.d/ directory. These scripts must be run using sudo or root privileges and are also used to retrieve the status of individual services or the entire environment. There are dozens of different microservices, and many have dependencies on other microservices, so the start sequence is essential to understand.

SAS has recommended downloading the Ansible-based Viya-Ark (VARK) playbook that helps to streamline a lot of these processes It is a Linux package you download from GitHub, that downloads a series of Ansible playbooks to your environment for Ansible to run. It includes many helpful playbooks that will greatly simplify tasks such as, starting/stopping, upgrading, and applying hotfixes, as well as preinstall/post-install checks.

4. Manage your hardware

Software is loaded onto hardware and your software can only run as effectively as your hardware will allow. Stray processes, hung jobs, CPU or memory limitations; these are all things that can affect your hardware in a negative way, which in turn can limit or halt proper usage of the Viya environment. Knowing how to check and manage the disk, processes, and memory usage, are all valuable tools in troubleshooting. Gridmon is an extremely valuable built-in tool on Linux environments that run Viya, which allows you to see active processes, hardware resource consumption, and environment information across all the nodes.

5. Know your users (SAS, CAS, Individual accounts)

User accounts are highly important in a Linux environment. They are what allow or prevent various actions to be taken by the software. Many times, these restrictions are intentional but often they’re not. Knowing what these accounts are used for can help you to understand the distinction.

There are two Viya specific accounts that are created during install:

The SAS user is known as the “installer” account. This means most of the files and logs that are created during and after your installation will be owned by the SAS user. As an admin, you should have access to this account, as its main purpose after installation is to be used administratively. It is created automatically during install and is used to start/stop all the various Viya microservices.

The CAS user is an “internal-use only” account that various Viya microservices use to securely run the processes, rather than the administrator. However, it’s still important to know about it. Any process run using a CAS statement will run on the OS side under the CAS user.

6. SAS Content and Data

A common topic of confusion is the difference between what gets stored physically on the disk, and what gets stored in Viya’s internal Postgres database. In the Viya Environment Manager webapp, administrators can view and edit permissions on various reports that they or others have created. The confusing part is that these reports are not stored on the OS side, or at least not in any meaningful way to the administrator. Instead, they’re stored in Viya’s Postgres database, in a format only Viya can read. All the tools for administering these reports are given to us in the environment manager. Alternatively, the actual datasets that these reports are created from are stored on the OS side, in one of the defined caslibs.

7. Logs, and maintaining them.

The first step in fixing anything is to see what happened. Every microservice in a Viya environment has a logfile that it outputs to. By default, you see this in /opt/sas/viya/config/var/log. It is also common to see this directory symlinked to /var/log.

Log files typically append to the same file continuously until the process associated with the file is killed. Then a new one is created and the old one remains static on the disk. It doesn’t take long for the cycle to accumulate a very large number of files on your disk. Certain processes such as the CAS logs or the workspace logs, can accumulate very rapidly.

Manually removing old log files is a solution but ideally, you would set up a cronjob that would automate this process for you. Your client may have certain retention policies you need to be aware of, but typically logs are kept anywhere from 1 week to 1 month in time before they’re deleted.

Conclusion

Like all powerful software tools, SAS Viya needs to be monitored and maintained. Knowing some of the basics will allow you to get started on your journey to become a professional SAS Viya administrator.